The present invention relates to computer software compilation systems and methods which support run-time data type identification of instantiations of classes. In this patent document, instantiations of classes are also called objects.
Specifically, the present invention relates to computer software compilation systems and methods which support run-time data type identification of objects in computer programming languages which support polymorphism. Polymorphism is the ability to call a variety of functions using exactly the same interface. The present invention is adapted and intended to operate with computer programming languages (such as C++) which use derived classes and virtual functions to implement polymorphism, where virtual function calls are implemented as indirect function calls through tables of function addresses generated by compilers. Such tables are called virtual tables.
This patent document often refers to a C++ computer programming language to illustrate the features, structure, and operation of the present invention. This patent document also refers to the C++ computer programming language to describe the background of the present invention.
However, the references to the C++ computer programming language are included in this patent document for illustrative purposes only. The present invention is not limited to the C++ computer programming language. Rather, the present invention is adapted and intended to operate with computer programming languages which support polymorphism and which use virtual tables to store virtual member function addresses. The C++ computer programming language is an example of such a computer programming language.
Conventional C++ translators, compilers, and debuggers do not support run-time data type identification of objects in computer programs. In other words, accurate data type information for the objects in the computer programs which are produced using the conventional C++ translators and compilers is not available at run-time. Consequently, the conventional C++ debuggers are not adapted to extract and utilize the accurate, run-time data type information for the objects in the computer programs which are produced using the conventional C++ translators and compilers.
The unavailability of such data type information during run-time limits the functionality of the debuggers. For example, without access to such data type information during run-time, the debuggers cannot reliably refer to pointers and reference variables to determine and use the actual data types of the objects (where the pointers and reference variables point to the objects). Also, the debuggers cannot reliably use the pointers and reference variables to completely and accurately display the objects' contents.
Also, the availability of such data type information during run-time could be used as the basis for providing innovative type inquiry operators in languages such as C++. Such operators would be useful when writing code which needs to identify the exact data types of the objects.
The problem identified above is described below in greater detail with reference to FIGS. 1 and 2.
Referring first to FIG. 1, suppose the statements in Table 1, below, are found in a C++ computer program.
TABLE 1 ______________________________________ class ANIMAL { public: virtual int x( ); virtual int y( ); }; ANIMAL *dog.sub.-- ptr = new ANIMAL; ANIMAL *horse.sub.-- ptr = new ANIMAL; int i; i = (*dog.sub.-- ptr).x( ); ______________________________________
ANIMAL is declared as a class having two virtual member functions, x() and y(). A dog.sub.-- ptr 136 and a horse.sub.-- ptr 134 are declared as pointers to type ANIMAL. The dog.sub.-- ptr 136 and horse.sub.-- ptr 134 are assigned to point to objects 124, 122, respectively, of type ANIMAL.
FIG. 1 graphically presents an object code representation 102 of the class and pointer declarations and the object instantiations from Table 1. The object code representation 102 is generated by the conventional C++ translators and compilers.
As shown in FIG. 1, the object code representation 102 includes a member function x() code segment 106 and a member function y() code segment 108. The object code representation 102 also includes a virtual table 104 which is associated with the class ANIMAL. Generally, virtual tables are associated with classes that contain virtual member functions.
The virtual table 104 includes an entry 110, 112 for the member function y() and an entry 114, 116 for the member function x(). Generally, virtual tables associated with a class include one entry for each member function in the class.
The entry 110, 112 for the member function y() includes a field 112 that contains a pointer 118 to the member function y() code segment 108. The pointer 118 represents a virtual member function address of the member function y() code segment 108. The entry 110, 112 also includes a field 110 that contains information related to calling the member function y() code segment 108.
The entry 114, 116 for the member function x() includes fields 114, 116 that are analogous to those of the entry 110, 112 for the member function y().
The objects 122, 124 of the type ANIMAL include self-descriptive information. The self-descriptive information includes virtual table address fields 126, 128, respectively. The virtual table address fields 126, 128 contain virtual table addresses 130, 132, respectively, which point to the virtual table 104 associated with the class ANIMAL. Generally, objects of the same class contain virtual table addresses which point to the same virtual table.
In Table 1, the statement EQU i=(*dog.sub.-- ptr).x();
calls the member function x() associated with the object 124 pointed to by the dog.sub.-- ptr 136 (and also associated with the ANIMAL class) and assigns the integer returned by x() to a variable i. The member function x() code segment 106 is accessed via the pointer 120 in the virtual table 104. The virtual table 104 is accessed via the virtual table address in the object 124. The object 124 is accessed via the dog.sub.-- ptr 136.
Referring now to FIG. 2, suppose the statements in Table 2, below, are found in the C++ computer program.
TABLE 2 ______________________________________ class ONE { public: int I1; virtual int mem.sub.-- 1( ); }; class TWO { public: int I2; virtual int mem.sub.-- 2( ); }; class Three: public ONE, public TWO { int I3; }; THREE *Ptr3 = new THREE; ______________________________________
ONE is declared as a class having a data member I1 and a virtual member function mem.sub.-- 1(). Similarly, TWO is declared as a class having a data member I2 and a virtual member function mem.sub.-- 2(). THREE is a derived class of the ONE and TWO classes and has a data member I3.
A Ptr3 226 is declared as a pointer to the class THREE and is assigned to point to an object 202 of the class THREE.
FIG. 2 graphically presents an object code representation 102 of the statements from Table 2. Specifically, FIG. 2 graphically presents an internal layout of the instantiated object 202 of the class THREE. The object code representation 102 is generated by the conventional C++ translators and compilers.
As shown in FIG. 2, the object 202 includes the data members I1 206, I2 210, and I3 214. The object 202 also includes a virtual table address field 208 which contains a virtual table address 220 of a virtual table 216. The object 202 also includes a virtual table address field 212 which contains a virtual table address 222 of a virtual table 218. The virtual tables 216, 218 are similar to the virtual table 104 shown in FIG. 1.
Since the Ptr3 226 is declared as a pointer to the class THREE, the debugger and the innovative type inquiry operators can use the Ptr3 226 to determine the actual data type of the object 202. Also, since the Ptr3 226 points to the beginning of the object 202, the debugger can use the Ptr3 226 to completely and accurately display the contents of the object 202.
Instead of containing the statement, EQU THREE *Ptr3=new THREE;
suppose Table 2 contained the statement, EQU ONE *Ptr1=new THREE;
This new statement declares a Ptr1 224 as a pointer to the class ONE. However, this statement assigns the Ptr1 224 to point to the object 202 of the class THREE.
As shown in FIG. 2, because Ptr1 224 points to the beginning of the object 202, the debugger can use the Ptr1 224 to completely and accurately display the contents of the object 202. However, because Ptr1 224 is declared as a pointer to the class ONE, the debugger and the innovative type inquiry operators cannot use the Ptr1 224 to determine the actual data type of the object 202.
Instead of containing the statement, EQU ONE *Ptr1=new THREE;
suppose Table 2 contained the statement, EQU TWO *Ptr2=new THREE;
This new statement declares a Ptr2 228 as a pointer to the class TWO. However, this statement assigns the Ptr2 228 to point to the object 202 of the class THREE.
As shown in. FIG. 2, because Ptr2 228 is declared as a pointer to the class TWO, the debugger and the innovative type inquiry operators cannot use the Ptr2 228 to determine the actual data type of the object 202. Also, because Ptr2 228 does not point to the beginning of the object 202, the debugger cannot use the Ptr2 228 to completely and accurately display the contents of the object 202.
Therefore, as illustrated in FIGS. 1 and 2 and as described above, the conventional C++ translators, compilers, and debuggers are inadequate in that they do not support run-time data type identification of objects in computer programs.
Prior approaches for solving such inadequacies of the conventional C++ translators, compilers, and debuggers involve explicit user intervention. Under these prior approaches, computer programmers are required to modify class declarations in the computer programs by adding additional members to the class declarations. The additional members are used to store the actual data types of the objects. Specifically, by operation of external tools, predefined virtual member functions, or the conventional C++ compiler, the actual data types of the objects are stored in the additional members. Consequently, data type identification of the objects during run-time is possible by referring to the additional members.
The prior approaches, however, are faulty in that they are not transparent to the computer programmers. Also, since the computer programmers are required to explicitly modify the class declarations, the prior approaches are laborious and error-prone.